I hope this PR gets accepted, we have been using James' patch in our project, adding very useful functionality. Kudos to James and @dkerr64 .

Thanks for putting this all together David. Hopefully will be accepted into base.

I thought I would document a printer use case for this enhancement.
If you have a WiFi guest VLAN and you want to permit guest devices to print or access a Apple TV then you need to enable mDNS-SD reflection and open firewall rules between the guest VLAN and the LAN on which the printers or Apple TV reside.

By default avahi-daemon will reflect all mDNS-SD messages which will potentially cause many more services to be broadcast onto the guest VLAN which is undesirable. This enhancement lets you control which services are published onto the guest VLAN so that e.g. only printing services are published.

For printers add the line...
reflect-filters=_printer._tcp.local,_ipp._tcp.local,_pdl-datastream._tcp.local
and now only printing services will be reflected into your guest VLAN.

This in itself is not enough, you must also open up firewall ports to allow traffic from guest VLAN to the IP address of the printer(s). With iptables this would look like...

-A <your forward chain> -s 192.168.101.0/24 -d 192.168.1.8/32 -p tcp -m tcp --dport 515 -j ACCEPT
-A <your forward chain> -s 192.168.101.0/24 -d 192.168.1.8/32 -p tcp -m tcp --dport 631 -j ACCEPT
-A <your forward chain> -s 192.168.101.0/24 -d 192.168.1.8/32 -p tcp -m tcp --dport 9100 -j ACCEPT

Where 192.168.101.0/24 is guest network and 192.168.1.8 is IP address of printer on your main LAN.

A similar method can be used to enable access to AirPlay devices, though the firewall rules are more complex.

David

As mentioned in my previous comment, AirPlay can also be enabled across LANs. In this example I have tested using the AirServer application on a Apple Mac, not with a genuine Apple TV. Different rules may be required for a genuine Apple TV.

In avahi-daemon.conf...
reflect-filters=_airplay._tcp.local,_raop._tcp.local,_device-info._tcp.local

Firewall iptables rules...

-A <your forward chain> -s 192.168.101.0/24 -d 192.168.1.5/32 -p tcp -m tcp --dport 5001 -j ACCEPT
-A <your forward chain> -s 192.168.101.0/24 -d 192.168.1.5/32 -p tcp -m tcp --dport 7000 -j ACCEPT
-A <your forward chain> -s 192.168.101.0/24 -d 192.168.1.5/32 -p tcp -m tcp --dport 7001 -j ACCEPT
-A <your forward chain> -s 192.168.101.0/24 -d 192.168.1.5/32 -p tcp -m tcp --dport 49152 -j ACCEPT
-A <your forward chain> -s 192.168.101.0/24 -d 192.168.1.5/32 -p udp -m udp --dport 6010 -j ACCEPT
-A <your forward chain> -s 192.168.101.0/24 -d 192.168.1.5/32 -p udp -m udp --dport 6011 -j ACCEPT
-A <your forward chain> -s 192.168.1.5/32 -d 192.168.101.0/24 -p udp -m udp --sport 6012 -j ACCEPT

Where 192.168.101.0/24 is guest network and 192.168.1.5 is IP address of Mac running AirServer on your main LAN.

Note, ports may be different for a real Apple TV or other AirPlay device (e.g. a AirPlay speaker) or any other mDNS-SD You can use tcpdump to identify them. You can also run avahi-daemon --debug to see which mDNS-SD messages are getting reflected or rejected, this can be helpful when initially setting up a new device to be reflected.

David

Thanks for your contribution, and testing reports. I would be happy to include this once I've reviewed it.

I noticed at WWDC that Apple added support for Bluetooth beacons to show or highlight nearby printers from Bonjour.. I desperately hope they add this for airplay targets as well.

@lathiat any chance we can have this merged into the master please? We have been running this in production on astlinux (http://www.astlinux-project.org/) for close to 9 months now without problems. Thanks

@lathiat Can you please review this pull request and comment or merge into the master please.
Thank you

@lathiat Can you please review this pull request and comment or merge into the master please.Thank you

Sounds like a really good enhancement to Avahi. Thank you!

Thank you. I just wish @lathiat would merge into master.

I am looking for exactly this! I hope it gets merged soon.

@lathiat Could you please merge @dkerr64's awesome pull request?

@dkerr64 I build from source with your patch and ran it, but unfortunately it is still reflecting all services, not only the once allowed with reflect-filters. I uncommented the example line you provided in the avahi config file for my testing:

reflect-filters=_airplay._tcp.local,_raop._tcp.local

These are the steps I took to build from source:

autoreconf -i
autoconf configure.ac
./configure --prefix=/usr        \
            --sysconfdir=/etc    \
            --localstatedir=/var \
            --disable-mono       \
            --disable-python     \
            --disable-qt5 
make
sudo make install

Did I do something wrong?

Chris @cpoetter, thanks for posting your question. I tested on my network today and it is working as expected. I assume you have two networks (e.g. 192.168.1.0/24 and 192.168.2.0/24) and that avahi is running on a box that is connected to both? My conf file includes this section...

[reflector]
enable-reflector=yes
reflect-ipv=no
reflect-filters=_printer._tcp.local,_ipp._tcp.local,_pdl-datastream._tcp.local,_airplay._tcp.local,_raop._tcp.local,_device-info._tcp.local,_googlecast._tcp.local,_googlerpc._tcp.local,_googlezone._tcp.local

And I confirmed by connecting an iPhone to one network and using the Discovery app (https://itunes.apple.com/us/app/discovery-dns-sd-browser/id305441017?mt=8) and it only showed those devices from the other network that broadcast one of the above tags. If I comment out the reflect-filters statement and restart the daemon then dozens of Bonjour/DNS-SD names are visible.

David.

Chris @cpoetter, I should add that some devices, including iPhones/iPads/Macs cache Bonjour/DNS-SD replies.. so if you start out testing by reflecting everything, then change to a selective list, then that device will still have in its cache the full list. I don't know how long it takes for the cache to flush.
David

@wisd0me found a memory leak in the filter which he fixed. That prompted me to look at the file and I found another instance of the same leak so I added fix for that. Once again I ask @lathiat to please merge this pull request or at least comment on this thread.

I suggest splitting this pull request and moving the avahi-core/iface.c change which suppresses the spurious log messages into a separate PR. It has nothing to do with the feature being introduced here and will have better chances to get merged, IMHO.

I suggest splitting this pull request and moving the avahi-core/iface.c change which suppresses the spurious log messages into a separate PR. It has nothing to do with the feature being introduced here and will have better chances to get merged, IMHO.

As this PR has been siting here for over 3 years without comment from @lathiat I doubt there is very much I could do short of appealing to him yet again to consider merging this. I will await his guidance.

THANK YOU @lathiat

Please excuse my ignorance but how do I apply this patch to my current Avahi running on Ubuntu 16..04?